\documentclass[%
	%draft,
	%submission,
	%compressed,
	final,
	%
	%technote,
	%internal,
	%submitted,
	%inpress,
	%reprint,
	%
	%titlepage,
	notitlepage,
	%anonymous,
	narroweqnarray,
	inline,
	twoside,
        %invited,
	]{ieee}

\newcommand{\latexiie}{\LaTeX2{\Large$_\varepsilon$}}

%\usepackage{ieeetsp}	% if you want the "trans. sig. pro." style
%\usepackage{ieeetc}	% if you want the "trans. comp." style
%\usepackage{ieeeimtc}	% if you want the IMTC conference style

% Use the `endfloat' package to move figures and tables to the end
% of the paper. Useful for `submission' mode.
%\usepackage {endfloat}

% Use the `times' package to use Helvetica and Times-Roman fonts
% instead of the standard Computer Modern fonts. Useful for the
% IEEE Computer Society transactions.
%\usepackage{times}
% (Note: If you have the commercial package `mathtime,' (from
% y&y (http://www.yandy.com), it is much better, but the `times'
% package works too). So, if you have it...
%\usepackage {mathtime}

% for any plug-in code... insert it here. For example, the CDC style...
%\usepackage{ieeecdc}

\begin{document}

%----------------------------------------------------------------------
% Title Information, Abstract and Keywords
%----------------------------------------------------------------------
\title[MBOX Services]{Middlebox Service Negotiation}

% format author this way for journal articles.
% MAKE SURE THERE ARE NO SPACES BEFORE A \member OR \authorinfo
% COMMAND (this also means `don't break the line before these
% commands).
\author[Anupam Ashish]{\authorinfo{Anupam Ashish follows a master
thesis at the ComSys Group, RWTH Aachen University, Aachen, Germany.
e-mail: anupam.ashish@rwth-aachen.de}}


\maketitle

%\begin{abstract}
%\end{abstract}

%\begin{keywords}
%\end{keywords}

%----------------------------------------------------------------------
% SECTION I: Introduction
%----------------------------------------------------------------------
\section{Introduction}
The internet as we see today stands on three important components: computing platforms (end-points), packet transport ( i.e internetworking) infrastructure and services (application) \cite{rfc4423}. This architecture of internet combined with tightly associated global namespaces of Internet Protocol (IP) and Domain Name Service (DNS) have made the internet scalable to the point where it can support billions of devices and millions of services. However, the coupling of the role as a locator and an identifier in IP and the delegable nature of hierarchically assigned Domain Names have led to the situation where it is very difficult to maintain anonymity. Also, with advent of different on-path devices which offer services other than packet switching and routing it gets increasingly messy to support them in the existing infrastructure. These on-path devices or middleboxes as we will call in this document offer services like QoS, VPN or firewall require active feedback from the end-points about contexts like user, application and host. Furthermore, the current architecture of transport layer has been designed for end to end delegation and communication. So for the active functioning of these middleboxes they need to be empowered in a way which is not feasible in current IP architecture. In this document we will look into how to provide these middleboxes with parameters to participate actively as an on-path devices.

According to Lixia Zhang, `` a middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between the source host and the destination host " \cite{rfc3234}. In a classical sense, internet architecture can be seen as an hour glass model, wherein all the upper layer protocols ride over the single IP protocol which itself rides over a variety of hardware layer protocols. It is equally important to observe that end-to-end principles are great at some functions like security, reliability and performance. However, these middleboxes inserted in the network offer numerous services other than just IP forwarding and challenge the traditional hour-glass model of internet. And altogether they help in diversifying the concentration of functions in end systems to throughout the network. This distribution of roles and functions in the network creates some concerns \cite{rfc3234},
\begin{itemize}
\item New middleboxes challenge the old protocols which had been designed without the consideration for middleboxes.
\item New failure modes caused by introduction of middleboxes because now rerouting of IP packets in case of router failure is not the only concern. Sessions involved around the crashed routers also need to be handled.
\item Middleboxes also need to be configured and managed which was earlier limited to the end points.
\item Analyzing failures and misconfigurations is complex.
\item Middleboxes may request for more information for the service provided by them.
\end{itemize} 

At present, middleboxes can provide a lot of functionalities and services but most of the time they do not have enough have information from the end points. Consider the situation as shown in Figure 1 where an end-point within an enterprise network located in Aachen requires to connect to an end-point in the enterprise network of the same firm but located in Berlin. As enterprises are concerned about security and privacy, it would require the connection between the two end-points to be secure. Also, enterprises are very particular about their resources. So, connection from a mail client in Aachen to a mail server in Berlin is of higher priority than that of a file transfer between the two end-points. A QoS box residing on the path between the two end-points can request for information about the application which initiated the connection. Since mail-clients hold a higher priority. the QoS box will prefer the connection of the mail-client. This is a simple example where middleboxes can participate actively to provide various services rather than. In the context of the above we can see that various service providers can be located on the network path and some of them can convey to the end points as to which of the services they provide. Also they can request some more information from the end-points in order to fully or partially provide the service or completely deny the service. However, providing services is just one dimension. 
\begin{figure}[h!]
  \caption{Role of middleboxes in the Network}
  \centering
    \includegraphics[width=0.5\textwidth]{middlebox_problem.pdf}
\end{figure}
Another dimension is to observe other requirements like privacy and anonymity. Apart from being on the receiving end of the services often the end-points request for anonymity or privacy to the middleboxes and require that the response in correspondence to the request be visible only to the requester. The fact that the responder (end-point) may have only one public key pair and the corresponding certificate, he would want it to be available only to those who request for it. Using public keys very clearly pose a privacy problem because they directly identify the end-point and for the end-point with a single public key identify all the transactions made by it. With the help of public key cryptography and having multiple public key pair we can achieve these requirements but it is not very efficient in a service provider scenario. A middlebox can provide service to thousand of end-points and for each service it will be a tiresome task for it to keep up with the verification of identity and decryption of the cipher-text using public key cryptography. So this brings us to the realization that more efficient mechanisms are needed for identity protection and anonymity.

We have already seen that traditional internet protocols do no play well with middlebox. Host Identity Protocol which is a cryptographic namespace above the IP and DNS namespace provides us with a suitable base to design our solution for the middlebox service negotiation without worrying about the shortcomings of the traditional internet protocol. Hence, the focus in this document will be on HIP aware middleboxes.  Several middlebox extensions related to HIP are already available like HIP middlebox authentication extension and HIP registration extension \cite{rfc5203}. Heer, Wirtz and Varjonen discuss a new HIP parameter that helps service providers to share properties and requirements of a service to the HIP end-hosts and to on-path HIP network entities \cite{draft-heer-hip-service-01}. Moreover, Henrik Ziegeldorf has already provided with a signaling mechanism for the middleboxes wherein various contexts like host, user or application certificates can be shared and verified \cite{henrik}. However, in our case we want to deal not only with service negotiation from the point of view of the middlebox but also anonymity and privacy from the point of view of end-hosts. In the following section we will provide a design to support service negotiation keeping anonymity and privacy in perspective.

%----------------------------------------------------------------------
% SECTION II: Problem Statement
%----------------------------------------------------------------------
\section{Problem Statement}
In the previous sections we have defined middleboxes, given a brief overview of the challenges they face in the current implementation of internet architecture and also discussed why service negotiation is important for the full functioning of the middlebox and how relevant is identity protection in perspective of end-points . Also previously, Henrik Ziegeldorf has provided an architecture based on HIP to have feedback mechanism for the middleboxes wherein they can complement the traffic with more information \cite{henrik}. This enables the initiator or the responder to answer with appropriate information which can be cryptographically verified by the middleboxes and hence empower the middlebox to take decisions actively based on contexts like user, application and host. 

However, the above mechanism does not provide identity protection and limited visibility of the information. A simple example of limited visibility would be the initiator responding with information which can be read only by the chosen middleboxes and not by everybody on the network path. In identity protection the end-points can choose to be anonymous. Apart from the identity protection and anonymity, a good extension for middleboxes would be to communicate to the end point about the service they provide and hence request for specific information. This in turn will help the end points to respond only with the required information.

Firstly, we have to enable the middleboxes with mechanisms to to publish the type of service they provide and also with the ability to request for specific information depending on the policy. And for this HIP Parameters form a very suitable carrier as they can be both signed and unsigned. Currently, with Henrik's architecture we have an extra signaling message ``I3" to complete the HIP Base Exchange \cite{henrik} and we would also like to remove the extra overhead created by it. 
\begin{figure}[h!]
  \caption{Service Negotiation in context of middlebox}
  \centering
    \includegraphics[width=0.5\textwidth]{Service_Negotiation.pdf}
\end{figure}

A middlebox can have very little information about the initiator (host, user and application context) in the I1 message, it is not possible for the middlebox to add requests or more information as a HIP Parameter. As we can see in the Figure 2, in the first response R1 (from the responder) the middlebox can attach an signed or unsigned HIP Parameter, ``SERVICE\_OFFER", publishing information about the service it provides and information it requires from the initiator. This information required by the middlebox can be more specific like the information about USER\_ID or host certificates. Additionally, a signed SERVICE\_OFFER may contain the public key of the middlebox and the certificate chain or a certificate chain pointer corresponding to the public key. The middlebox may also chose to sign the SERVICE\_OFFER paramter, hence it can be verified by the end-point.

On receiving the R1 message with the SERVICE\_OFFER the initiator would verify the offer in case it is signed and may chose to provide the information required by the middlebox in order to avail the service. It may also chose not to provide all the information but only a limited or restricted version of it. Furthermore, the initiator may request for identity protection and privacy. The verification of the offer may fail if the certificate chain is corrupted or is not valid.  In that case also the initiator may provide only a limited or restricted information. 

In response to R1, initiator can either send a SERVICE\_ACK or a SERVICE\_NACK. If it choses to acknowledge and avail the service it will respond with an acknowledgement to it and the end-point information as requested in the service offer. In case the verification of the service offer has failed, it can reply with a SERVICE\_NACK, so that the middlebox can try sending the certificate chain again. Also, if the initiator requests for identity protection it may chose to encrypt the end-point information so that it can be visible only to those who requested for it.

Similarly, the middlebox box can also chose to offer similar services to the other side of the communication channel i.e responder. So, for the responder the middlebox can add SERVICE\_OFFER in the I2 message and the responder can respond to the SERVICE\_OFFER in the R2 message.  It is important to emphasize that in a typical signaling scenario, there might be more than one on-path devices or multiple middleboxes. Hence, verification of  service offer from multiple middleboxes and responding with end-point information encrypted differently to each middlebox is a huge overhead. Also, public key infrastructure with certificate chains are additional overhead on the signaling path. We need additional mechanism to prevent the public key to be revealed to entities which did not make the request.  

%----------------------------------------------------------------------
% SECTION III: Conclusion
%----------------------------------------------------------------------
\section{Conclusion}



\bibliographystyle{plain}
\bibliography{abstract}

\end{document}
